Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Display labels instead of icons in top toolbar. #24304

Merged
merged 29 commits into from
Sep 2, 2020

Conversation

tellthemachines
Copy link
Contributor

Description

Fixes #10524 , along with #24234 . This PR points to #24234 so that only the changeset related to displaying button labels in the top toolbar is visible.

All the feedback and comments from #15830 have been addressed. One point that I'd appreciate further feedback on is the positioning of nested dropdowns, such as:

Screen Shot 2020-07-31 at 3 45 49 pm

How has this been tested?

Tested in browser at different breakpoints. Keyboard navigation checked.

Screenshots

Types of changes

New feature (non-breaking change which adds functionality)

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
  • I've updated all React Native files affected by any refactorings/renamings in this PR.

@tellthemachines tellthemachines added [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). General Interface Parts of the UI which don't fall neatly under other labels. labels Jul 31, 2020
@tellthemachines tellthemachines self-assigned this Jul 31, 2020
@github-actions
Copy link

github-actions bot commented Jul 31, 2020

Size Change: +2.19 kB (0%)

Total Size: 1.17 MB

Filename Size Change
build/block-editor/index.js 126 kB +89 B (0%)
build/components/index.js 200 kB +13 B (0%)
build/edit-post/index.js 305 kB +569 B (0%)
build/edit-post/style-rtl.css 6.26 kB +645 B (10%) ⚠️
build/edit-post/style.css 6.24 kB +637 B (10%) ⚠️
build/edit-site/index.js 17 kB +51 B (0%)
build/edit-widgets/index.js 12 kB +61 B (0%)
build/editor/index.js 45.4 kB +125 B (0%)
ℹ️ View Unchanged
Filename Size Change
build/a11y/index.js 1.14 kB 0 B
build/annotations/index.js 3.67 kB 0 B
build/api-fetch/index.js 3.44 kB 0 B
build/autop/index.js 2.82 kB 0 B
build/blob/index.js 620 B 0 B
build/block-directory/index.js 7.99 kB 0 B
build/block-directory/style-rtl.css 953 B 0 B
build/block-directory/style.css 952 B 0 B
build/block-editor/style-rtl.css 10.8 kB 0 B
build/block-editor/style.css 10.8 kB 0 B
build/block-library/editor-rtl.css 8.55 kB 0 B
build/block-library/editor.css 8.55 kB 0 B
build/block-library/index.js 136 kB 0 B
build/block-library/style-rtl.css 7.47 kB 0 B
build/block-library/style.css 7.47 kB 0 B
build/block-library/theme-rtl.css 741 B 0 B
build/block-library/theme.css 742 B 0 B
build/block-serialization-default-parser/index.js 1.88 kB 0 B
build/block-serialization-spec-parser/index.js 3.1 kB 0 B
build/blocks/index.js 47.7 kB 0 B
build/components/style-rtl.css 15.5 kB 0 B
build/components/style.css 15.5 kB 0 B
build/compose/index.js 9.67 kB 0 B
build/core-data/index.js 12.3 kB 0 B
build/data-controls/index.js 1.29 kB 0 B
build/data/index.js 8.55 kB 0 B
build/date/index.js 5.38 kB 0 B
build/deprecated/index.js 772 B 0 B
build/dom-ready/index.js 568 B 0 B
build/dom/index.js 4.48 kB 0 B
build/edit-navigation/index.js 11.6 kB 0 B
build/edit-navigation/style-rtl.css 1.16 kB 0 B
build/edit-navigation/style.css 1.16 kB 0 B
build/edit-site/style-rtl.css 3.06 kB 0 B
build/edit-site/style.css 3.06 kB 0 B
build/edit-widgets/style-rtl.css 2.46 kB 0 B
build/edit-widgets/style.css 2.45 kB 0 B
build/editor/editor-styles-rtl.css 492 B 0 B
build/editor/editor-styles.css 493 B 0 B
build/editor/style-rtl.css 3.81 kB 0 B
build/editor/style.css 3.81 kB 0 B
build/element/index.js 4.65 kB 0 B
build/escape-html/index.js 733 B 0 B
build/format-library/index.js 7.71 kB 0 B
build/format-library/style-rtl.css 547 B 0 B
build/format-library/style.css 548 B 0 B
build/hooks/index.js 2.13 kB 0 B
build/html-entities/index.js 621 B 0 B
build/i18n/index.js 3.57 kB 0 B
build/is-shallow-equal/index.js 710 B 0 B
build/keyboard-shortcuts/index.js 2.52 kB 0 B
build/keycodes/index.js 1.94 kB 0 B
build/list-reusable-blocks/index.js 3.12 kB 0 B
build/list-reusable-blocks/style-rtl.css 476 B 0 B
build/list-reusable-blocks/style.css 476 B 0 B
build/media-utils/index.js 5.32 kB 0 B
build/notices/index.js 1.79 kB 0 B
build/nux/index.js 3.4 kB 0 B
build/nux/style-rtl.css 671 B 0 B
build/nux/style.css 668 B 0 B
build/plugins/index.js 2.56 kB 0 B
build/primitives/index.js 1.41 kB 0 B
build/priority-queue/index.js 789 B 0 B
build/redux-routine/index.js 2.85 kB 0 B
build/rich-text/index.js 13.9 kB 0 B
build/server-side-render/index.js 2.77 kB 0 B
build/shortcode/index.js 1.7 kB 0 B
build/token-list/index.js 1.27 kB 0 B
build/url/index.js 4.06 kB 0 B
build/viewport/index.js 1.85 kB 0 B
build/warning/index.js 1.14 kB 0 B
build/wordcount/index.js 1.17 kB 0 B

compressed-size-action

@mapk
Copy link
Contributor

mapk commented Aug 3, 2020

Thanks for this PR! I spent some time working with the previous design explorations and wanted to present my further iterations here. While this isn't direct feedback on the PR (yet), I thought it best to share on this PR for a discussion as to what path works best.


Option 1 - Add labels under icons

txt-under-icons

  • Reduce the active state of the Settings icon from 36px to 32px. This allows more room for text and aligns it to the same size as the Inserter.

Option 2 - Expand height of topbar

76px

  • Height has been expanded from 60px to 76px to allow more room for text.
  • The "W", at this size, feels too big to be full bleed. I dropped it down a bit and pulled it away from edges.
  • The right side buttons feel a little out of alignment and would need further iterations.

Option 3 - Smaller icons

smaller-icons

Mobile

Screen Shot 2020-08-03 at 4 47 00 PM

  • I resized the icons from 36px to 28px. This doesn't align with our standard icon size, but does allow for more breathing room when icon labels are visible.
  • With the smaller icons, the positioning of the Publish button doesn't feel so bad.
  • Again, the Settings icon active size matches the Inserter size.

Option 4 - Text only

Screen Shot 2020-08-03 at 4 48 42 PM

Mobile

mobile

  • Eliminate all icons (as this PR does already).
  • I've explored several iterations with the Mover text.
  • As shown in the Mobile view, it would be better to display the block's name in the toolbar rather than just "block".

Feedback

I wanted to get these early iterations up for discussion. Is there an option that feels better than the others? What else would you like to see iterated? If you're interested in more, check out my Figma file.

Copy link
Member

@noisysocks noisysocks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice job! Seems to work pretty well. Waiting for design to be finalised before I test thoroughly.

packages/components/src/dropdown-menu/index.js Outdated Show resolved Hide resolved
@mapk
Copy link
Contributor

mapk commented Aug 4, 2020

Here's my feedback on the current state of this PR:

Text only

I love the text only mode because it's so clean. But once the Top Toolbar option is introduced, it feels a little wonky. This PR chooses to keep the block toolbar on a second row, which could work, but would need updating to text only as well. (I think that's reserved for another PR)


Top Toolbar mode

The bottom border is missing in the second level toolbar here:

Screen Shot 2020-08-04 at 4 04 00 PM


Site icon

I don't think we need to add text here. It just gets very out of place and messy.

Screen Shot 2020-08-04 at 3 58 38 PM


Text edits

  • "Add block" should just be "Add"
  • "Block navigation" should just be "List view"

Settings button

This looks more like a button now than a toggle now. Should keep this pattern?


Button sizes

When both menu dropdowns are triggered, the "Add block" and "Publish" btns sizes are more visibly unequal and look like a mistake. I think they should all match sizes with this option.

Screen Shot 2020-08-04 at 4 14 29 PM


Dropdown menus should not overlap

These dropdowns should appear next to their parent level menu.

Example 1

menu-drops

Example 2

drop2


Settings item when in dropdown

I think we should drop the "active" state of the Settings item when it's in the dropdown. More like this:

Screen Shot 2020-08-04 at 4 26 29 PM


Dropdowns

I think we have a standard min-width on dropdowns like 258px. Let's apply that to these as well.


After these changes, I'm happy to provide another review. 😄

@tellthemachines
Copy link
Contributor Author

I've left this in labels-only mode for now, we can always change it later if we decide it doesn't work. Or we could have three options: icons only, icons and labels, and labels only 😄

I've addressed most of @mapk 's feedback; all but the dropdown positioning as I'm still tussling with the Popover component on that front. Hopefully will have it fixed soon!

The e2e tests are failing because of the changes I made to the label text on some of the buttons. I'd appreciate any feedback on those changes, so that I can fix the tests once they're sorted.

@mapk
Copy link
Contributor

mapk commented Aug 5, 2020

Thanks for the quick turnaround, @tellthemachines! As you're working through this, I hope providing a bit more feedback is okay. If you'd like me to hold off until a certain point, just let me know.

Top Toolbar mode

I noticed that when selecting Top Toolbar mode, when I don't have a block selected the topbar bottom border doubles up.

border


Text buttons

When switching to a text only mode, I really think all the button interactions should work the same. It always felt odd to me to have icon buttons (ie. hover and pressed states) display differently than the text buttons, and now that these are all text buttons, it's even more obvious.

An open question: Should the text only buttons reflect the same interactions that the Preview button has. These are no longer icon buttons, and should probably now reflect the interactions of our standard button states.

btns


Settings and Options

I just noticed that when both Settings and Options are in a dropdown, and activated, they both show blue. This doesn't feel right to me even though technically it is. Maybe fixing the whole button interaction thing will help this?

Screen Shot 2020-08-05 at 10 46 11 AM


Icon dropdown

In text only mode, when the screen size is reduced, the buttons all move to a dropdown that is represented only with an icon. Does this make sense in the text only mode? Should we have a label for this icon?

Screen Shot 2020-08-05 at 10 57 31 AM


There are so many small nuances that come to light as this gets developed, so I really appreciate your time with it all.

@ZebulanStanphill ZebulanStanphill added the Needs Accessibility Feedback Need input from accessibility label Aug 5, 2020
@mapk
Copy link
Contributor

mapk commented Aug 5, 2020

If we converted all the topbar text-only buttons to the default button instance as outlined in our Figma libraries, they would interact similarly to the Preview button. Check out this prototype below: (please ignore the black background)

btns

@tellthemachines
Copy link
Contributor Author

As you're working through this, I hope providing a bit more feedback is okay.

Absolutely, all feedback helps!

I noticed that when selecting Top Toolbar mode, when I don't have a block selected the topbar bottom border doubles up.

Hmm, I can't reproduce this. Have you checked out my latest changes?

In text only mode, when the screen size is reduced, the buttons all move to a dropdown that is represented only with an icon. Does this make sense in the text only mode? Should we have a label for this icon?

Very good question 😅
I'm happy to try out a text label here, just not sure what to call it (we don't currently have an aria-label on this button, so I guess that'll need addressing either way). "More settings" seems a bit weird/redundant?

I've switched all the text buttons to behave like the Preview button in my latest commit, let me know if it works!

Regarding the dropdown positioning issues, it's trickier than I thought initially. The Popover component that we use in dropdowns has very limited positioning capabilities. We have #21275 to address that, and from the looks of it it's going to require rewriting the whole component. I repositioned the Outline dropdown the best I could, but haven't been able to improve any of the others. Can we leave it as is for now, and revisit once Popover is rebuilt?

@mapk
Copy link
Contributor

mapk commented Aug 10, 2020

I've switched all the text buttons to behave like the Preview button in my latest commit, let me know if it works!

After sitting on this one for a few days, I'm not fond of how our default button state looks for each of these topbar items. I iterated further with something more reminiscent of our Icon Button styles. It's not perfect, but the other direction felt overwhelming.

  • The gray pressed state is replaced with a simple 1.5 pixel blue border.
  • I aligned with the recent PR to make the text links in the topbar blue instead of black.
  • Hovered states are identified with a border as are the active states.

icon-like-buttons

Next steps

  • Iterate when the Top Toolbar mode is "on". How do the toolbar buttons look when there are gray dividers?
  • Explore other interaction designs.

@mapk
Copy link
Contributor

mapk commented Aug 11, 2020

I got some feedback yesterday that moving to "text only" might be too much. The text only version loses hierarchy and grouping which can cause usability issues.

I'm exploring a couple icon + text solutions to see how else we might be able to retain some sense of hierarchy and relationship once we introduce text into the topbar.

cc @kellychoffman

@mapk
Copy link
Contributor

mapk commented Sep 1, 2020

Caught some spacing issues on smaller screens.

spacing

@mapk
Copy link
Contributor

mapk commented Sep 1, 2020

Generally, the spacing in between these buttons all feels a bit off.

These all feel too close.

Screen Shot 2020-09-01 at 3 50 10 PM

These feel too far from one another.

Screen Shot 2020-09-01 at 3 50 19 PM

Is there a way to make this more consistent across all the buttons in text-only mode? In this Figma mockup, I have them spaced 10px apart.

good-spacing

Figma mockup

@ZebulanStanphill
Copy link
Member

10px isn't aligned to our grid system, but yeah, something close to that would make sense.

Base automatically changed from add/icon-labels-option to master September 2, 2020 00:23
@tellthemachines tellthemachines merged commit e703aee into master Sep 2, 2020
@tellthemachines tellthemachines deleted the add/top-toolbar-labels branch September 2, 2020 00:24
@github-actions github-actions bot added this to the Gutenberg 9.0 milestone Sep 2, 2020
@ZebulanStanphill
Copy link
Member

Noting that #24965 has been created to discuss improvements to the "Options" modal, which should help solve some of the overly-similar labels currently present.

See also these other issues relating to the top toolbar:

@talldan
Copy link
Contributor

talldan commented Sep 2, 2020

@mapk Was wondering why 'Outline' was used for the button text that opens the List View, instead of 'List View'?

Looking back through the designs in the comments, it looks like at one point it said 'List View' (#24304 (comment)) but then changed in the more recent designs.

edit: Oh, I notice the tooltip currently says 'Outline' for the icon button, so that's probably why. I was wondering if we want to stick with List View in both places.

@mapk
Copy link
Contributor

mapk commented Sep 2, 2020

@ZebulanStanphill, changing the spacing to 12px is totally fine.

@talldan, No problem changing it to "List View". Let's make that happen. :)

@afercia
Copy link
Contributor

afercia commented Sep 2, 2020

Glad to see this merged! Thanks everyone for the perseverance and I'd like to thank @nicolad who started the first attempt to build this in #15830 ❤️ (deserves props).

Regarding this point by @ZebulanStanphill:

Really, the block inspector shouldn't even be accessed from the top toolbar in the first place; it should be accessed from the block toolbar, and it should act like a modal, to better fit accessibility guidelines.

Ah! That's what the accessibility team has been asking in the last... years? Considering all the troubles for keyboard navigation to go from the selected block to the inspector and back, the teams asked several times to have the inspector "in place" close to the block instead of in the sidebar. Hopefully there will be new explorations in this direction.

@afercia
Copy link
Contributor

afercia commented Sep 2, 2020

I'd like to propose props also for @tomjn who created the original issue, together with @nicolad who, as mentioned above, worked hard on the first PR.

@tomjn
Copy link
Contributor

tomjn commented Sep 3, 2020

I actually raised the issue during a user group after a discussion with @mikelittle, he deserves the props :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). General Interface Parts of the UI which don't fall neatly under other labels. Needs Accessibility Feedback Need input from accessibility Needs Design Feedback Needs general design feedback.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Optional Inline Labels in Toolbar